Generally, the present application relates to data processing. More specifically, the application is related to techniques for managing access by impersonation in an access management system.
Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to a client (e.g., client application at a device) of the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser at a client makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser at the client receives a token that may be used to access the human resources application.
In an enterprise, users (e.g., employees) typically may have access to one or more different systems and applications. Each of these systems and applications may utilize different access control policies and require different credentials (e.g., user names and passwords). A user wanting to access multiple resources protected by an access management system may need to be authenticated based on credentials provided to the access management system. A successful authentication gives the user authorization to access the protected resources, based on their assigned access privileges.
Upon authentication, the access management system may establish a session (“user session”) to provide the access granted to the protected resource(s). For a user session, the access management system may maintain session information at a computing system (e.g., server computer) for the user session. The session information maintained by access management system may be referred to as a server-side session. The access management system may store session information for the server-side session that defines the access granted to the user and the constraints of the session. The session information for a server-side session may be mapped to a client, which is provided with a token. In the instance where a single sign-on (SSO) session is established, the access management system enforces access for SSO based on the token.
If a user wants to access multiple resources protected the access management system, the access management system may determine whether the user is authenticated to access the multiple resources requested by a user. In some instances, authentication of a user for one resource may suffice for accessing other resources; otherwise, the access management system may request additional credentials from the user. Upon authentication to access multiple resources, the user may not need to re-authenticate to access additional resources. In such instances, the access management system may maintain a single session, such as a single sign-on session (SSO), which provides a user with access to multiple resources after authentication.
Some access management systems may provide a feature (“impersonation”) that enables a user (“impersonatee”) to designate other users (“impersonators”) to act on their behalf for accessing one or more resources. An access management system may enable an impersonatee to temporarily assign his /her privileges to a user who will act as an impersonator of the impersonatee.
An impersonator can initiate a session (“impersonation session”) on behalf of an impersonatee to access one or more resources based on the privileges assigned to the impersonator. The access management system may verify that the impersonator is in fact authorized to impersonate the impersonatee. Upon verification of the impersonator, a session may be established as an impersonation session to enable the impersonator to access one or more resources according to the privileges assigned by the impersonatee. The access management system may provide an application for impersonation. An impersonation session can be established using the application.
Access management systems that support impersonation may be limited in enabling an impersonatee to manage and control an impersonation session in a fine-grained manner. New techniques are desired for managing impersonation sessions.